131–140 of 183 posts
Extending CSS with things such as LESS and SASS means I don't have to relearn everything. I just have to learn about the new features that actually bring something to the table.
Earlier quoted context omitted.
I see where you are getting into... But not pure, please, but reactive. One creates events on HTML and Javascript (there are a few by default), CSS filters, maps, and uses them.
The part of the system I was talking about would be a static component beneath the level of scripting and events. At that level the document can be considered a static snapshot of the state. The evaluation of each of the property values would be single expressions that could draw upon the state as input and produce style properties as a result. There should be no lifetime of the execution beyond that single evaluatio…
What events bring (besides generalizing the :hover-like pseudo-selectors into something more powerfull) is better separation of concerns. Instead of your Javascript touching several elements styles, it generates an event, and you describe how to handle it at the styling sheet.
Earlier quoted context omitted.
Someone yell at me if I'm wrong, but isn't TeX designed for paged content? That means while TeX might work amazingly for paginated content, single page apps, or really any non-paginated content, is very much a screwdriver where a hammer should be used scenario.
Overall it is, but when the above commenter mentions box-and-glue, they're talking about the building blocks of the line breaking algorithm TeX uses (you can read about it in this paper: http://onlinelibrary.wiley.com/doi/10.1002/spe.4380111102/ab... ). The box-and-glue system is a way of expressing a layout as an optimization problem (in the paper, they talk mostly about determining line breaks within a paragraph, b…
Solving LP is fast, especially when many of your constraints are equality constraints (as would be when specifying tables).
Most "problems" with CSS (with the exception of vertical centering and a few others) are caused by the fact that people can't be bothered to learn CSS. It's funny: if a programmer is told to write CSS but doesn't know how, he'll copy-and-paste from Stack Overflow, get a shit result, and say that CSS sucks. If a programmer is told to write Elm but doesn't know how, he'll learn the language, write some decent Elm, and…
Graphical layout is one of the most underestimated challenges in computer science. Programmers instinctively look at the problem and thing "oh, this is logical, I'll just whip up some basic principles and layout primitives and I'll have this solved in no time!" No, you won't. Designing a layout framework is really, really hard. Designing one that is simultaneously expressive enough to handle all of the crazy corner c…
> We finally shove bytecode-level runtimes into a browser and let a thousand flowers bloom asm.js and PNaCl are here today. What more are you expecting?
Earlier quoted context omitted.
1. Someone _has_ come up with the One True Layout System. It's just that most people like to pretend TeX doesn't exist or, when they grok the box-and-glue layout model, try to reinvent it from scratch.
does TeX have responsive layout with a variable document width? For the past year my ability to use CSS alone to convert an existing HTML Website and make it work on mobile has been putting food on my table. Could I be using TeX for the same thing?
(different paper formats, two columns, two pages per one landscape paper, four pages per one portrait paper... all with the same content)
CSS is broken. I've just been watching a colleague learning HTML/CSS for the first time. HTML was easy and she has a very good handle on that, producing some nice HTML5 markup by hand very quickly. CSS has been a nightmare - mostly not because of selectors or values (that comes later), but because of basic layout issues caused by the nasty hacky layout model of CSS - in particular the concepts of floats, block and in…
Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to appease the tableless zealots. I can remember wrestling for hours with simple layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve those layouts in mere minutes with ta…
At a fundamental level, what's missing is the ability to add a link rel=chrome tag in a document's header, such that you'd only sends a header with a title, that link rel=chrome tag, and its contents within the body. The header, footer, navigation items, etc. should all be defined outside of the document itself, as part of the chrome.
Put another way, a level of abstraction is still missing in the web developer's toolkit. Over the years, we've been compensating by:
1. mixing chrome and content together in html documents
2. sending boat loads of chrome-related styles alongside
Add to this that a great many web developers received little to no education in computer science, and it's no wonder that web development is such a mess.
Does anyone think it'd be a good idea for browsers to support more than one toolset? Right now it's just HTML+CSS+JS, no matter what languages people build on top of that assembly. Elm seems like a neat idea, but based on Paul's post, I dislike the fact that it compiles down to CSS. It seems a disingenuous way to present the language. I'd much rather a browser was simply told this was an application/elm or something…
Also browsers work because of standards. It's not about the "best", but about agreeing.
Recently I see many people trying to make one suboptimal thing by starting from scratch, removing all standards compatibility, throwing away all the knowledge that went in to a thing to make this one single thing work better, resulting only in incompatibilities, non-standards-conformance and making everything else than that one thing harder or even impossible.
You can see this with web frameworks, with system tools, etc.
Usually this stems from people knowing how to use stuff, but not understanding concepts or why things are the way they are.
This is actually also true for CSS. CSS was meant to support all kinds of output devices, regardless of being graphical or not, support screens in all sizes and nowadays people use it to only really support a low number of "pixelperfect" screen sizes with default settings. Everything else is completely broken.
Nobody even bothers to look at new CSS3 features, new HTML 5 elements (unless it is for SEO), etc. In the end nobody is interested in implementing it correctly which usually results in standards to only slowly advance and having individual vendors only implementing their favorites or even their proposals and experiments, rendering the standard itself unusable, because of it being implemented by one single vendor.
In the end we live in a world where the only thing that's really common inside the infrastructure are hacks to work around those problems.
Most developers hoped this would change after Firefox ate a big part of IEs market share, but currently it seems to be repeating.
Btw. I am not excluding myself from these things. I don't actively work into other directions and basically do the same things.
Before you disagree: If you have something about CSS in your resume. Did you ever even completely read through CSS standards?
I've always been dubious about how well that mantra applies to web applications, but conventional wisdom certainly has it that content and layout separation works most strongly for documents; but Mike's work shows that layout can be a powerful component of messaging.
Producing pieces like the ISIS layout requires a much richer concept of separating the layers that go into the final presentation; paragraphs of text associated with geographical regions, times, and news events are the content items - not simple divs with classes, but rich objects. Choosing then how to lay those out is clearly far beyond the capabilities of CSS. And while in theory the layout logic to display a scrollable strip map with location markers could be reused for another story, in truth that layout is part of this article, not a generic 'stylesheet' that would be shared by a number of documents containing similar objects.
We need tools that facilitate creation of procedural layouts. CSS has its place in specifying typographic conventions, but it's a hindrance to making more interesting content-led layouts.
Am I the only one who actually likes CSS? I tend to find can do pretty much any design that I've been tasked with without using graphics. For example: http://justinvincent.com/page/2043/anatomy-of-a-native-feeli... But I will admit it has taken 17 years to get to that place.
E.g. add a second button "calculate totals" under "done", but ensure that they always have the same height if one contains a line break. Maybe it's possible with flexboxes, but no client will let me target IE 10+.