I think using inline styles might be both maintainable and scalable but it
might require a different way of thinking about the app.
You can structure the views to have a second parameter that would contain
device information like size and DPI and you could case on that info and
have totally different layouts for each class of device. One layout for
phones, one for tablets, one for desktops.
These layouts could share a lot in common by abstracting certain widgets
and by using responsive techniques. For example, you can have a highly
specialized mobile version and have the tablet and the desktop look more or
less the same.

CSS was created for presentation back when the web was about documents and
it makes perfect sense to have that separation for a document.
What we have now are web apps and these are in a completely different
category.
Layout for a web app IS part of the critical information. It encapsulates a
lot from the UX of that app.



On Mon, Jun 6, 2016 at 3:24 AM, Tim Stewart <finelinestu...@gmail.com>
wrote:

> This is a very interesting discussion which I think is covering two
> vectors - firstly, is statically typed CSS better that traditional approach
> (with or without CSS pre-processor), and secondly is inline CSS better than
> stylesheet. On the first, there seems to be different opinion, depending to
> some extent on background, as well as David's suggestion of turning one
> into the other, which may be the best of both worlds.
>
> On the second point though, I really don't get the appeal of inline CSS.
> One of the things I reckon the web got right was decoupling presentation
> from structure and behavior. In Android and iOS SDK development, the two
> are combined into a single file, in each case a dialect of XML. So what
> happens when you want your app to have a different appearance on different
> screen sizes or orientations? You produce a whole different XML file for
> that media size. That's Apple's official advice - at least last time I last
> looked at iOS native development. By having to duplicate the entire view
> structure, you double your maintenance overhead and introduce an
> opportunity for bugs to creep in where you change an identifier in one XML
> file, say, but not the matching identifier in a different layout's file.
>
> With CSS media queries, while not perfect, you get to define everything
> that stays the same just once, and media-specific aspects as appropriate -
> with source grouped together for that media size. Now, you can put media
> queries into inline CSS I guess (is that what you guys are doing?) but then
> your conditional layout logic is spread all over the place.
>
> And then your styles are replicated into the DOM on each individual node.
> If you have an component type repeated 1000 times, that's 1000 times the
> same style code gets added in and re-evaluated by the browser. Browsers
> render CSS fast, but still that just seems wrong.
>
> I guess if your app doesn't care about media size and doesn't have 1000
> components then this is just a non-issue, but I struggle with the concept
> of this being maintainable and scalable.
>
> On Fri, Jun 3, 2016 at 7:40 PM, David Legard <daleg...@gmail.com> wrote:
>
>> How difficult would it be to write an automated script to turn CSS into
>> Elm-Css?
>>
>>>
>> i.e. to turn
>>
>> h1 {
>>     background-color: green;
>> }
>>
>> into
>>
>> h1 = style ["background-color","green"]
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to