9 ms·

To me an evident thing in UI development is that separating stylesheet from layout isn't really a thing anymore and the benefits of this separation aren't reall

To me an evident thing in UI development is that separating stylesheet from layout isn't really a thing anymore and the benefits of this separation aren't really that clear. Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout and allow for much better accessibility, tooling, overall thinking of how UIs work. So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?

Bahamut 7y ago
This is not quite necessarily true - I work at a tech giant and we've opted for using scss still & are quite happy with our choice.
- sktrdie 7y ago
  Is your company actually building a platform for developers to build apps? Because that's what Apple is doing and they shifted away from using paradigms like CSS.
  - ohrus 7y ago
    CSS is not a paradigm. Whatever workflow you have for styling your pages and apps, it's all CSS in the end.
    - orf 7y ago
      CSS can certainly be described as a paradigm. It's a model you follow to style things on the web. It also doesn't matter if it's all CSS in the end. At one particular end it's all manipulating assembly instructions, but I wouldn't call styling pages writing assembly. That is to say the underlying model or paradigm (styling in this case) doesn't really matter if you build an abstraction on top of it that hides that paradigm.
      - ohrus 7y ago
        Sure, you're right in that sense, thought I do not agree with the comparison to writing assembly. The phrase "shifting away" from CSS is what I was addressing my initial comment towards, and I don't believe that using a paradigm on top of CSS would constitute a shift away from CSS... you're still using plenty of CSS rules whether you use styled-components, modules, SCSS, etc.
    - underwater 7y ago
      CSS is absolutely a paradigm. Not the specific style rules that exist in browsers, but the idea of selectors, specificity and stylesheets. The fact that it's possible to define layout and styling using just style properties is the giveaway.
  - Bahamut 7y ago
    I work for Apple.
    - jxub 7y ago
      One of HN's wonderful moments :)
tannhaeuser 7y ago
CSS definitely can get in the way with far-distance effects in MVw apps. It tends to not being particularly representative of how you think about and modify the app during development, nor during maintenance. Though you still need media queries since you can't use these and eg :visited etc as inline styles. The reasoning behind this asymetry isn't entirely clear to me; it seems to be a syntactic accident. Actually, I think CSS sucks at most things. Now CSS grid and flexbox are sold as solutions for long-standing layout deficiencies - and they undoubtly are a progress over grid frameworks using floats. But the real question is what is gained by pretending we're editing a hierarchical document (using HTML envisioned for casual academic publishing like it's 1999) when we layer a layout engine on top of it complicated enough to abstract that 1999s HTML into a grid and constraint-based layout? Why not just write markup representing that conceptual layout in the first place? We now have an enormous syntax proliferation of a markup language with an additional, redundant, and idiosyncratic item-value syntax (CSS) but still can't specify layout constraints in their more natural form as systems of inequalities.
sureaboutthis 7y ago
> Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout That's what we call JavaScript and CSS. You can do that without React and my company has been doing that for 15 years quite successfully--with separation of the elements and styling. How do you think SwiftUI and React do such things? With JavaScript and CSS! (Sorry if I have factual errors about SwiftUI cause I really don't know anything about it.)
danShumway 7y ago
I work as a web developer for an enterprise-level software company. Experimented a bit with CSS-in-JS, which is designed to get rid of this separation, and I found it to ultimately be harder to maintain than SCSS. This process was also what got me hooked on BEM after being initially pretty skeptical about whether it had any real value. I now believe that BEM would meet the needs of most teams, with the exception of a few massive software houses like Facebook. And most companies don't fall into the Facebook category, even if they think they do. I've also taken some time to reflect on older companies I've worked for, particularly some work I did at Oracle, which was for a reasonably large team spread across several continents. I think BEM would have been good enough for us there as well. I would propose the following test: Is your front end in a monorepo? If so, BEM is probably good enough to solve any problems with scope and style conflicts. If your code can fit in a monorepo, I think its unlikely you will ever have a legitimate reason to duplicate a component name in multiple places. Take it or leave it, just my experience, I'm sure other people would advocate different things. But it's by no means a settled debate, different people/orgs have come to different conclusions. It's just that one side writes a lot more blog posts.
- Waterluvian 7y ago
  What made CSS in js harder for you?
  - danShumway 7y ago
    So obviously, all of this is just opinion me. To start with, the only good way to do CSS in JS is to use a library that compiles your styles at runtime and inserts them into the document under a style tag. If you're not doing that, you lose the ability to use pseudo-elements and pseudo-selectors like hover. Probably 95% of the time, using CSS will be easier than setting up an event system to monitor all of this stuff yourself. React's default tutorials will almost always tell you to pass styles manually into components, and ironically this reintroduces a lot of the problems with cascade that we're trying to avoid, because it's very easy to apply multiple styles in the wrong order or forget that some style is getting overridden. It can also make it very difficult to figure out where styles are coming from in code. So definitely don't follow that advice -- at the very least use a runtime compiler that doesn't spit out any inline styles. There are plenty of libraries that will handle runtime compilation, but many of them come with performance costs. Enterprise software has a reputation of being slow, for good reason -- it usually is slow, because it's framework heavy and handles weird edge cases, and it's developed by multiple people over multiple years. I worry about performance more at work than I do on personal projects. Aside from performance, I was finding that it was irritating to track class prefixes for dynamically compiled styles. One advantage of BEM is that it's really, really easy to debug. You always know exactly where a style is coming from, you always know where in code to find it, and you always know what class to use in the (hopefully rare) case that you need to hack together some selectors someplace in your code. On the ecosystem side of things, there are a number of tiny annoyances if you're using React -- Webpack can handle live style updates if you're compiling a stylesheet. If you're compiling your CSS in Javascript though, Webpack can only reload the entire page. I found this made iteration and design a lot slower. Maybe there's some setting someplace to fix that behavior, but I couldn't find it and I didn't want to waste the time trying to build my own solution. Finally, on a personal level, I was finding that putting my CSS in the same file as my component logic was making it very hard to organize everything and quickly grep sections of the code. This is probably personal preference for a lot of people, but I've found that disorganization is one of the biggest risks for large applications. Everyone tells me that you can still keep your JS-styles in a single file, and people will be good, and they won't split it across multiple sections of code or files -- I don't think that reflects the reality of most software development. I want the people I'm working with (and myself) to fall into a "pit of success" where organization is concerned. Putting all of that together, the biggest thing was that I was messing around with all of this technology, finding that it was not as tightly integrated or as seamless as everyone said it was, was spending a lot of time debugging stuff, and I asked myself -- why? IMO the biggest problems to solve with external CSS is style cascade, it's conflicting class names, it's selectors that apply across multiple components. BEM solves all of these problems for most codebases I've encountered, and doesn't require any extra libraries or frameworks. I hate debugging third-party code, and I can count on one hand the number of third-party libraries I've used on the web that I've never needed to debug. So a solution that solves all of the problems we face at work without introducing edge-case behaviors or extra dependencies is nearly always the right choice to make. There is a rare case where you want to make your own custom CSS behavior that can only be handled through Javascript, but this is usually a bad idea because of performance concerns, and it's usually better to handle that as a separate, global polyfill anyway.
thrower123 7y ago
I don't think it ever made sense. The biggest problem with CSS is that it is essentially global state, and you can get tricky action-at-a-distance effects that you never considered if you happen to wrrite some ids that something else is expecting to own and their selectors are poorly written. Or you can monkey-patch over it and break other things. Tightly scoping things can make CSS workable, but requires discipline. And things that require discipline to do right don't scale well.
- karaokeyoga 7y ago
  I agree. I have moved away from using IDs for CSS, though, as have a lot of other front-end developers. I use IDs strictly for JavaScript now. I was a happy user of IDs for CSS for probably twenty years but the transition away from that was largely painless and I don't feel like I lost anything along the way.
jjcm 7y ago
Personally I prefer a mix of both. For reusable components, I prefer inline styles. These are things that shouldn't be mutable without creating an exception to the design language. For basic page layout, standard stylesheets all the way. I shouldn't have to know react to make a marketing page that has nothing dynamic on it, but I'd still like to be able to reuse existing components on that page easily. Recently I've been using webcomponents a lot for this, mainly because it makes the code accessible for those who don't know javascript and don't have an environment set up - just load the script at the top of the page and you can use <my-component> wherever you want in the html with the styling/functionality already taken care of. With those in place anyone can update a css file to lay things out appropriately.
untog 7y ago
I don't think CSS is outdated, it was just never that suited for the purpose people are using it for. It still remains a fantastic way to style a document. The cascading nature of CSS works great in that context. But styling UI components is something quite different.
- wwweston 7y ago
  I'll bite: what's different about styling a UI? UIs are presumably more consistent/less varying than documents, so special cases and cascade overlaps should be less of a thing?
  - dmitriid 7y ago
    You accidentally apply a global style, and your entire UI is broken. You need a different styling inside a specific visual component? You need to fight specificity and override a parent ir a grandparent or a global style. In most UI systems this is not a concern.
    - geezerjay 7y ago
      > You accidentally apply a global style, and your entire UI is broken. That's only a concern if your UI elements depend on global styles, right? Meanwhile, UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs
      - majewsky 7y ago
        > UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs This statement makes it sound like every Qt application uses CSS. That's not true. CSS is offered as a way to apply corporate branding to an application. I'm not aware of any FOSS Qt applications using CSS.
        geezerjay 7y ago
        > This statement makes it sound like every Qt application uses CSS. That's not true. The applications that are ok with the default style don't need to specify style. Nevertheless Qt is an UI toolkit that supports CSS styling. > I'm not aware of any FOSS Qt applications using CSS. And that's ok. Nevertheless I've already worked on a couple of Qt projects that used Qt Style Sheets extensively. In fact, that's pretty much the norm in any non-desktop project.
rukuu001 7y ago
CSS that affects a components internal layout should be with the component. CSS that affects the components appearance (colours, type etc should be with the document). Of course, communication across teams will affect how successful this is. I’ve seen it go both ways. PS - read ‘should’ as ‘makes my life easier’
- tracker1 7y ago
  If using JSS, you can use a theme for common appearance settings, and use a context that carries that to all components. For example, material-ui uses this approach and I've found it works incredibly well in practice. I've added additional values as needed to my theme and this carries all the way down. This includes additional/adjusted fonts, colors, etc.
reaperducer 7y ago
to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this? As with anything in technology, it depends on the task and what you're trying to achieve. The size of the site is a major factor, as is how optimized the owner wants it to be. Saying that "big companies are definitely moving away" from anything is always going to be a gross and inaccurate generalization.
dragonwriter 7y ago
> separating stylesheet from layout isn't really a thing anymore It never was, layout is part of stylesheets. Do you mean separating content from presentation?
oefrha 7y ago
Separation of structure/content and presentation is great for textual content splintered with a few images, so it shines in blogs, news sites (in theory) and other types of informational sites (like documentation). I can give my blog a brand new look without touching any HTML markup, which is awesome. This separation does get in the way in certain modern web apps, where content is basically scrambled garbage without proper presentation.
otabdeveloper4 7y ago
HTML isn't about UI. Never has been and never will. The pain will continue until people understand.
- majewsky 7y ago
  HTML/CSS/JS is arguably the most successful UI platform in the world, so this is obviously wrong. You just want HTML to not be about UI.
  - otabdeveloper4 7y ago
    Something can be "not about UI" and "the most successful UI platform in the world" at the same time. Many such cases. :) Point is, HTML is a document format, not a UI toolkit. That's how it was designed and that's how it continues to evolve. This is probably not a ideal situation, but trying to change it now probably won't do any good.
    - contravariant 7y ago
      Well like it or not but the rise of REST APIs suggests that HTTP is extraordinarily well suited to use as a general interface so it's not too surprising that the related markup language HTML has found similar use as a user interface.
lmm 7y ago
I've been saying this for over ten years. Glad the world is kind of coming around to it. Almost all HTML is generated these days, and the information that's useful for styling is available in the same place as the information that's defining HTML. So generate the styling inline in the same place. If your address display component use a 14 point font, put that inline in the code that generates HTML for an address display component. If you need to change it for all addresses, you can change it in that code. If you need one address display to be special, use a subclass or whatever mechanism you would normally use for one special address display. Compress your HTML in transit if you're worried about the inline styles wasting bandwidth.
- chrshawkes 7y ago
  Already addressed earlier but inline styles ignore media queries so you may have missed the entire Web 3.0/4.0/responsive web design etc which occurred in 2012.
  - lmm 7y ago
    You mean changing the layout to be less useful on mobile (or occasionally making the layout less useful on desktop and changing to a better one on mobile)? Yeah, I'm pretty happy to have avoided that one.
    - chrshawkes 7y ago
      I don't blame you lol

Bahamut 7y ago

This is not quite necessarily true - I work at a tech giant and we've opted for using scss still & are quite happy with our choice.

sktrdie 7y ago
Is your company actually building a platform for developers to build apps? Because that's what Apple is doing and they shifted away from using paradigms like CSS.
- ohrus 7y ago
  CSS is not a paradigm. Whatever workflow you have for styling your pages and apps, it's all CSS in the end.
  - orf 7y ago
    CSS can certainly be described as a paradigm. It's a model you follow to style things on the web. It also doesn't matter if it's all CSS in the end. At one particular end it's all manipulating assembly instructions, but I wouldn't call styling pages writing assembly. That is to say the underlying model or paradigm (styling in this case) doesn't really matter if you build an abstraction on top of it that hides that paradigm.
    - ohrus 7y ago
      Sure, you're right in that sense, thought I do not agree with the comparison to writing assembly. The phrase "shifting away" from CSS is what I was addressing my initial comment towards, and I don't believe that using a paradigm on top of CSS would constitute a shift away from CSS... you're still using plenty of CSS rules whether you use styled-components, modules, SCSS, etc.
  - underwater 7y ago
    CSS is absolutely a paradigm. Not the specific style rules that exist in browsers, but the idea of selectors, specificity and stylesheets. The fact that it's possible to define layout and styling using just style properties is the giveaway.
- Bahamut 7y ago
  I work for Apple.
  - jxub 7y ago
    One of HN's wonderful moments :)

tannhaeuser 7y ago

CSS definitely can get in the way with far-distance effects in MVw apps. It tends to not being particularly representative of how you think about and modify the app during development, nor during maintenance. Though you still need media queries since you can't use these and eg :visited etc as inline styles. The reasoning behind this asymetry isn't entirely clear to me; it seems to be a syntactic accident. Actually, I think CSS sucks at most things. Now CSS grid and flexbox are sold as solutions for long-standing layout deficiencies - and they undoubtly are a progress over grid frameworks using floats. But the real question is what is gained by pretending we're editing a hierarchical document (using HTML envisioned for casual academic publishing like it's 1999) when we layer a layout engine on top of it complicated enough to abstract that 1999s HTML into a grid and constraint-based layout? Why not just write markup representing that conceptual layout in the first place? We now have an enormous syntax proliferation of a markup language with an additional, redundant, and idiosyncratic item-value syntax (CSS) but still can't specify layout constraints in their more natural form as systems of inequalities.

sureaboutthis 7y ago

> Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout That's what we call JavaScript and CSS. You can do that without React and my company has been doing that for 15 years quite successfully--with separation of the elements and styling. How do you think SwiftUI and React do such things? With JavaScript and CSS! (Sorry if I have factual errors about SwiftUI cause I really don't know anything about it.)

danShumway 7y ago

I work as a web developer for an enterprise-level software company. Experimented a bit with CSS-in-JS, which is designed to get rid of this separation, and I found it to ultimately be harder to maintain than SCSS. This process was also what got me hooked on BEM after being initially pretty skeptical about whether it had any real value. I now believe that BEM would meet the needs of most teams, with the exception of a few massive software houses like Facebook. And most companies don't fall into the Facebook category, even if they think they do. I've also taken some time to reflect on older companies I've worked for, particularly some work I did at Oracle, which was for a reasonably large team spread across several continents. I think BEM would have been good enough for us there as well. I would propose the following test: Is your front end in a monorepo? If so, BEM is probably good enough to solve any problems with scope and style conflicts. If your code can fit in a monorepo, I think its unlikely you will ever have a legitimate reason to duplicate a component name in multiple places. Take it or leave it, just my experience, I'm sure other people would advocate different things. But it's by no means a settled debate, different people/orgs have come to different conclusions. It's just that one side writes a lot more blog posts.

Waterluvian 7y ago
What made CSS in js harder for you?
- danShumway 7y ago
  So obviously, all of this is just opinion me. To start with, the only good way to do CSS in JS is to use a library that compiles your styles at runtime and inserts them into the document under a style tag. If you're not doing that, you lose the ability to use pseudo-elements and pseudo-selectors like hover. Probably 95% of the time, using CSS will be easier than setting up an event system to monitor all of this stuff yourself. React's default tutorials will almost always tell you to pass styles manually into components, and ironically this reintroduces a lot of the problems with cascade that we're trying to avoid, because it's very easy to apply multiple styles in the wrong order or forget that some style is getting overridden. It can also make it very difficult to figure out where styles are coming from in code. So definitely don't follow that advice -- at the very least use a runtime compiler that doesn't spit out any inline styles. There are plenty of libraries that will handle runtime compilation, but many of them come with performance costs. Enterprise software has a reputation of being slow, for good reason -- it usually is slow, because it's framework heavy and handles weird edge cases, and it's developed by multiple people over multiple years. I worry about performance more at work than I do on personal projects. Aside from performance, I was finding that it was irritating to track class prefixes for dynamically compiled styles. One advantage of BEM is that it's really, really easy to debug. You always know exactly where a style is coming from, you always know where in code to find it, and you always know what class to use in the (hopefully rare) case that you need to hack together some selectors someplace in your code. On the ecosystem side of things, there are a number of tiny annoyances if you're using React -- Webpack can handle live style updates if you're compiling a stylesheet. If you're compiling your CSS in Javascript though, Webpack can only reload the entire page. I found this made iteration and design a lot slower. Maybe there's some setting someplace to fix that behavior, but I couldn't find it and I didn't want to waste the time trying to build my own solution. Finally, on a personal level, I was finding that putting my CSS in the same file as my component logic was making it very hard to organize everything and quickly grep sections of the code. This is probably personal preference for a lot of people, but I've found that disorganization is one of the biggest risks for large applications. Everyone tells me that you can still keep your JS-styles in a single file, and people will be good, and they won't split it across multiple sections of code or files -- I don't think that reflects the reality of most software development. I want the people I'm working with (and myself) to fall into a "pit of success" where organization is concerned. Putting all of that together, the biggest thing was that I was messing around with all of this technology, finding that it was not as tightly integrated or as seamless as everyone said it was, was spending a lot of time debugging stuff, and I asked myself -- why? IMO the biggest problems to solve with external CSS is style cascade, it's conflicting class names, it's selectors that apply across multiple components. BEM solves all of these problems for most codebases I've encountered, and doesn't require any extra libraries or frameworks. I hate debugging third-party code, and I can count on one hand the number of third-party libraries I've used on the web that I've never needed to debug. So a solution that solves all of the problems we face at work without introducing edge-case behaviors or extra dependencies is nearly always the right choice to make. There is a rare case where you want to make your own custom CSS behavior that can only be handled through Javascript, but this is usually a bad idea because of performance concerns, and it's usually better to handle that as a separate, global polyfill anyway.

thrower123 7y ago

I don't think it ever made sense. The biggest problem with CSS is that it is essentially global state, and you can get tricky action-at-a-distance effects that you never considered if you happen to wrrite some ids that something else is expecting to own and their selectors are poorly written. Or you can monkey-patch over it and break other things. Tightly scoping things can make CSS workable, but requires discipline. And things that require discipline to do right don't scale well.

karaokeyoga 7y ago
I agree. I have moved away from using IDs for CSS, though, as have a lot of other front-end developers. I use IDs strictly for JavaScript now. I was a happy user of IDs for CSS for probably twenty years but the transition away from that was largely painless and I don't feel like I lost anything along the way.

jjcm 7y ago

Personally I prefer a mix of both. For reusable components, I prefer inline styles. These are things that shouldn't be mutable without creating an exception to the design language. For basic page layout, standard stylesheets all the way. I shouldn't have to know react to make a marketing page that has nothing dynamic on it, but I'd still like to be able to reuse existing components on that page easily. Recently I've been using webcomponents a lot for this, mainly because it makes the code accessible for those who don't know javascript and don't have an environment set up - just load the script at the top of the page and you can use <my-component> wherever you want in the html with the styling/functionality already taken care of. With those in place anyone can update a css file to lay things out appropriately.

untog 7y ago

I don't think CSS is outdated, it was just never that suited for the purpose people are using it for. It still remains a fantastic way to style a document. The cascading nature of CSS works great in that context. But styling UI components is something quite different.

wwweston 7y ago
I'll bite: what's different about styling a UI? UIs are presumably more consistent/less varying than documents, so special cases and cascade overlaps should be less of a thing?
- dmitriid 7y ago
  You accidentally apply a global style, and your entire UI is broken. You need a different styling inside a specific visual component? You need to fight specificity and override a parent ir a grandparent or a global style. In most UI systems this is not a concern.
  - geezerjay 7y ago
    > You accidentally apply a global style, and your entire UI is broken. That's only a concern if your UI elements depend on global styles, right? Meanwhile, UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs
    - majewsky 7y ago
      > UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs This statement makes it sound like every Qt application uses CSS. That's not true. CSS is offered as a way to apply corporate branding to an application. I'm not aware of any FOSS Qt applications using CSS.
      - geezerjay 7y ago
        > This statement makes it sound like every Qt application uses CSS. That's not true. The applications that are ok with the default style don't need to specify style. Nevertheless Qt is an UI toolkit that supports CSS styling. > I'm not aware of any FOSS Qt applications using CSS. And that's ok. Nevertheless I've already worked on a couple of Qt projects that used Qt Style Sheets extensively. In fact, that's pretty much the norm in any non-desktop project.

rukuu001 7y ago

CSS that affects a components internal layout should be with the component. CSS that affects the components appearance (colours, type etc should be with the document). Of course, communication across teams will affect how successful this is. I’ve seen it go both ways. PS - read ‘should’ as ‘makes my life easier’

tracker1 7y ago
If using JSS, you can use a theme for common appearance settings, and use a context that carries that to all components. For example, material-ui uses this approach and I've found it works incredibly well in practice. I've added additional values as needed to my theme and this carries all the way down. This includes additional/adjusted fonts, colors, etc.

reaperducer 7y ago

to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this? As with anything in technology, it depends on the task and what you're trying to achieve. The size of the site is a major factor, as is how optimized the owner wants it to be. Saying that "big companies are definitely moving away" from anything is always going to be a gross and inaccurate generalization.

dragonwriter 7y ago

> separating stylesheet from layout isn't really a thing anymore It never was, layout is part of stylesheets. Do you mean separating content from presentation?

oefrha 7y ago

Separation of structure/content and presentation is great for textual content splintered with a few images, so it shines in blogs, news sites (in theory) and other types of informational sites (like documentation). I can give my blog a brand new look without touching any HTML markup, which is awesome. This separation does get in the way in certain modern web apps, where content is basically scrambled garbage without proper presentation.

otabdeveloper4 7y ago

HTML isn't about UI. Never has been and never will. The pain will continue until people understand.

majewsky 7y ago
HTML/CSS/JS is arguably the most successful UI platform in the world, so this is obviously wrong. You just want HTML to not be about UI.
- otabdeveloper4 7y ago
  Something can be "not about UI" and "the most successful UI platform in the world" at the same time. Many such cases. :) Point is, HTML is a document format, not a UI toolkit. That's how it was designed and that's how it continues to evolve. This is probably not a ideal situation, but trying to change it now probably won't do any good.
  - contravariant 7y ago
    Well like it or not but the rise of REST APIs suggests that HTTP is extraordinarily well suited to use as a general interface so it's not too surprising that the related markup language HTML has found similar use as a user interface.

lmm 7y ago

I've been saying this for over ten years. Glad the world is kind of coming around to it. Almost all HTML is generated these days, and the information that's useful for styling is available in the same place as the information that's defining HTML. So generate the styling inline in the same place. If your address display component use a 14 point font, put that inline in the code that generates HTML for an address display component. If you need to change it for all addresses, you can change it in that code. If you need one address display to be special, use a subclass or whatever mechanism you would normally use for one special address display. Compress your HTML in transit if you're worried about the inline styles wasting bandwidth.

chrshawkes 7y ago
Already addressed earlier but inline styles ignore media queries so you may have missed the entire Web 3.0/4.0/responsive web design etc which occurred in 2012.
- lmm 7y ago
  You mean changing the layout to be less useful on mobile (or occasionally making the layout less useful on desktop and changing to a better one on mobile)? Yeah, I'm pretty happy to have avoided that one.
  - chrshawkes 7y ago
    I don't blame you lol