Re: Browsers will never get it right [was Re:Blocked-base parsing?]

On 9/15/05, Emrah BASKAYA <emrahbaskaya@hesido.com> wrote:
> On Thu, 15 Sep 2005 05:43:37 +0300, Orion Adrian <orion.adrian@gmail.com>
> wrote:
> 
> > So I say that a new model is already upon us. I say that it's time we
> > took a look and see why so many people are starting to prefer RSS over
> > standard HTML feeds and in that view I find we'll see that client side
> > CSS and Javascript isn't a good solution.
> 
> You are over-simplifying the reason RSS became so popular. RSS did not
> become popular solely because it had little or no style information. Sure,
> their simplicity in not having fancy embedded styles does provide much
> wider access but it mainly allowed people to gather information on their
> favourite subjects without them having to visit each and every of their
> favourite sites. And let's not forget it is those sites that let them meet
> with RSS in the first place. I don't think people subscribe to an RSS feed
> just because they like their subjects, I'd assume they'd subscribe to the
> feeds of the sites they already like.

When providing an option though, people have consistently shown that
RSS is the preferred view for data. I don't argue that people
subscribe to sites they already like or that are suggested to them,
but that's because there isn't a good discovery mechanism yet other
than HTML. If there were, I'm fairly positive they would use that.
Where RSS kicks HTML's teeth in is in the idea that this is even
possible at all. RSS has a superior structure for this kind of content
and that's made possible by removing CSS and Javascripts as hurdles to
viewing a site. It's not like anybody thought to do this with the full
pages in HTML. RSS better structures the data making new capabilities
possible (e.g. tracking what you've read or haven't, marking posts for
keywords). Since the structure of an HTML document is unknown on any
give site beyond the required html, head, title and body elements, you
end up not being able to determine what is content and what isn't.
What headings are content headings and so on. A browser really can't
look at an HTML page and determine anything other than styling based
on CSS. RSS removes things it can't describe and properly marks up the
rest opening up new capabilities.

> On: Re: Block-based parsing; allow lies
> > At what level do we simply say no? To get the benefit we actually care
> > about, we're now writing multiple types of layouts.
> 
> Why do we have to say no? No one is forced to do multiple type of layouts.
> There'd be a need to do multiple types of layouts if the specs differed
> vastly, and in such a case, we'd awfully need such a solution anyway. And
> if we don't need such a solution for doing multiple layouts, I don't see
> the harm in having it. But from what I understand, you don't like authors
> to have control over the style they themselves have authored, and you
> don't like authors deciding what part of their content is considered more
> important through use of CSS and javascript, considering it is a bad
> thing. I don't consider that bad, and I am glad I don't browse the
> internet seeing the same style on web page.

Well it's inefficient and it raises the bar on everyone. But it's
still unnecessary. One can say, my page has this theme without
actually defining it on the server. Pages don't have to look the same,
but they do have to look alright when I decline their theme which
isn't a practical option right now as styling is very much intertwined
with content even if the files are separate since I know most people
don't write content first and then style, but write them in tandem.
Styling should be like a spec. It should be well defined what you're
targeting and all pages should be targetting it in the same way given
the same type of information.

> If we ditched author styling and javascript all together, I am 100% sure
> the authors would provide "recommended user styles" for their content, and
> even ones that are fully abiding to standards might feel the need to
> recommend a specific UA because its functions suit his site better, he
> couldn't fill in the gaps himself by providing a simple web-based
> application for certain operations going on in his site. We can't provide
> standards for every and every bit of detail, but only provide a general
> outline. An author can build his content around those standards, and
> create details with his own unique methods. Having the same exact DNA
> never could help any species, there has to be a flexibility for times when
> the need be.

This argument makes so sense to me? Doesn't that mean we should be
abandoning standards since products based on them have the same DNA?
Doesn't that mean we should all start using different languages, built
uniquely for us, so we have different DNA? RSS has managed to remove
the issues of the past. I have yet to see an RSS feed that says, best
viewed in X. That's an issue only when you allow styling code to be
determined by the author.

-- 

Orion Adrian

Received on Thursday, 15 September 2005 13:06:34 UTC