121–130 of 177 posts
Earlier quoted context omitted.
> Either make your web apps fallback to HTML + CSS So make two Web apps with the same functionality, basically?
Or make one app with an isomorphic base which gets progressively enhanced when JavaScript runs on the client.
Too bad, this is already implemented as a standard (cough-cough Mozilla) as part of Web Components. http://www.html5rocks.com/en/tutorials/webcomponents/imports... Reading the comments I felt many people thought this is an official recommendation. It's the mailing list folks, the same place where somebody suggested to replace JavaScript with AS3 because it would solve every problem of mankind.
If he likes this kind of writing his AJAX implementation he can easily do so by doing his own framework.
I think HTML5 is doing pretty, pretty good and it's underestimated in what it can be achieved.
[1] http://www.html5rocks.com/en/tutorials/webcomponents/custome...
I'm not necessarily opposed to something along these lines, except that it's basically already been tried: XSLT was essentially the inverse of this, where data endpoints were annotated with some static rendering descriptors. To me the XSLT approach seems cleaner, in that the URLs the browser is visiting are for the raw data itself, the URL scheme between machine and human is identical, and so on. XSLT also encouraged…
> XSLT has died a gentle death Maybe it is not because that XSLT is complex, but because XML has failed to become a language for the web. JSON has come to be the preferred choice. Which brings me to JSON and complexity: The complexity of retrieving data has been paved over multiple times using libraries. This has encouraged people to skip XML and go directly to JSON. If retrieval of XML data, or better yet JSON data,…
Earlier quoted context omitted.
Strictness accomplishes nothing whatsoever. If you remove presentational elements, people just abuse semantic elements.
I would make parsers and generators much easier to write.
Earlier quoted context omitted.
I wish strict XHTML was taken more seriously. HTML is the structure, CSS is the look, and JavaScript is the logic. With a strict XHTML style you can further enforce this by removing former standards which don't follow that design (e.g. OnClick="" etc). HTML5 is alright, but I'd like to see a strict HTML5 which bans a ton of classic HTML4.1 elements completely and also follows XHTML's much more logical style (and bans…
Strictness accomplishes nothing whatsoever. If you remove presentational elements, people just abuse semantic elements.
Sure it does, it means it is impossible to mix logic or styling into your HTML inline. That makes HTML more maintainable and teaching it easier (less is always easier to teach than more).
What semantic elements are you worried about them abusing? I cannot think of a semantic element which replaces defunct presentational elements without any CSS (which would makes the entire argument redundant).
Earlier quoted context omitted.
Strictness accomplishes nothing whatsoever. If you remove presentational elements, people just abuse semantic elements.
> Strictness accomplishes nothing whatsoever. Sure it does, it means it is impossible to mix logic or styling into your HTML inline. That makes HTML more maintainable and teaching it easier (less is always easier to teach than more). What semantic elements are you worried about them abusing? I cannot think of a semantic element which replaces defunct presentational elements without any CSS (which would makes the enti…
The author needs to watch this a meditate on why Alan Kay said what he said about the web architecture: http://youtu.be/oKg1hTOQXoY
Earlier quoted context omitted.
Yep. I used to love XSLT -- working in it finally forced me to understand recursion at, like, a deep cellular level -- but the whole time I was using it I knew it was a doomed language (because most people don't want to have to understand recursion at a deep cellular level just to be able to lay out a damn web page.)
XSLT is still good to learn -- I think it's conceptually sound, but its implementations are often terrible. I think the big pain points for most people are how finicky XML is in general, but also that any libs you use to generate your XML and translate it require an absurd amount of configuration. Years ago, I saw all the weaknesses in mixed PHP/html for building pages, but all the server-side templating languages lo…
It gave us 90% of our API "for free": On any page you could add an argument to the URL to spit out the XML data for the page, and others to get the items on the page as ATOM or RDF.
The developers hated the constraints it placed on them. But it was exactly because of the things the developers were prone to doing that was the reason for structuring it that way in the first place.
Lots and lots of very bad ideas here -- backwards-incompatibility with previous versions of HTML is always a good litmus test that a proposal hasn't been thought through, as is "hey let's restructure everything around this one currently-fashionable design pattern". (I kind of love how he just casually embeds a SQL interpreter in the browser, too, that's a nice finishing touch.) But the main thing is that this doesn't…