12 comments

[ 4.5 ms ] story [ 39.5 ms ] thread
Actually this is in interesting point. One that, I suppose, XHTML was supposed to fix (but never did).

Developers are getting more and more into (it seems) semantic content. I like that - but I never really bother because, as this article points out, Html is too locked in anyway there is little point.

(incidentally it took me a while to take the article seriously... the image they used looks, well, like a penis...)

"Nobody seriously intends screenplays on the web to have the same function they do in real life: getting read, getting optioned or bought, and getting shot. All of that happens on paper, not on Firefox."

Why not? It's pretty straightforward to paginate something or divide it like a physical page. In the case of screenplays, the 'page' was engineered around because it was a physical limitation. The author's example of Final draft and it's default format of XML is exactly what I am talking about - scripting that to be presented in HTML is not difficult.

I feel like this entire article is complaining about HTML and HTML5, while reaching for tenuous examples and not really accomplishing much.

The biggest reasons 'why not' aren't technological, they are human. The Hollywood model for submitting scripts is extremely rigid in terms of how they should be formatted, and is built around having a physical copy of the manuscript. There's no real reason online submission can't work, other than the fact that it's not how things work at the moment.
Of course all documents can be a web page. Sumerian clay tablets can be a web page. Does it make sense to introduce hyperlinks and other markup to Sumerian clay tablets? Not to me, but that's something I don't feel the need to worry about.
Don't know much about the author and don't really understand his points .. I've always wondered who are writing and reading the List Apart .. For me looks like literature about web design and web frontend technology which is weird
Internal representation is different from display representation. So long as it looks good on a screen, I don't really care what the markup looks like.

You can then represent it internally in any format that you want. XML sounds good, because it is completely general, but that generality can also be a curse (due to its self descriptiveness, it is pretty much never the most compact way to represent structured data).

Screenwriters are old fashioned, but will definitely come around over time (just like filmmakers are slowly switching to digital). There are already web apps that allow you to write screenplays online - http://www.scripped.com is one. I'm sure that, in the long-term, the collaborative aspects of the web will trump any technical difficulties.

This example seems almost unbelievably bad.

Screenplays have well defined rules of organization and formatting that actually lend themselves nicely to being represented in HTML.

I might be an ill-trained author, but I don't mind writing

    <h2 class="stage-direction">
instead of

    <stagedirection>
I think (X)HTML + CSS is extensible enough for me. The former is only slightly less readable than the latter for maintainers of my code, and my paramount goal for the rendered document can be achieved equally well with both.
Well I'm certainly an ill-trained author and it seems to me that the details of the markup are wholly irrelevant to the people actually writing and making movies.

The screenwriter should be chugging along with (e.g.) a dialect of markdown that keeps the details the hell out of his way. Whether the markup that comes out the other side looks like XML or HTML just doesn't matter.

And "1 page = 1 minute" is a dodgy heuristic* that could easily be supplanted by software that could process the source and know what's set direction, scene changes, dialogue, etc.

* "1 page = 1 minute" has long since gone from handy heuristic to self-reinforcing delusion.

Today, if a screenwriter is selling an average (hundred minutes, more or less) movie, he will ensure that his script is a hundred pages (more or less). He'll tweak margins, font sizes, spacing, descriptions and more. He doesn't want his masterpiece stigmatized when it makes the studio rounds just because it showed up thirty pages either side of proper.

And so it goes.

Although the title has link-bait value, if taken seriously I would say that it basically reveals an author with limited vision.

In my experience there are nearly no documents (that have any significant value to me) that I would not want to see "webified". I love the options provided - to excerpt, cut/paste, add links, etc. Needless to say... no big scribd fan here.

Wow, alistapart has jumped the shark, I fear.

This article is just complaining about a whole host of non-problems. He's just made the case that there should be a microformat for screenplays, and a tool to convert the Final Draft XML format into said microformat, and some CSS to style it nicely. The <hr> tag is pretty much a perfect analog to the screenplay page break.

As for MathML, there are authoring tools that a) convert handwritten math equations to mathml and b) convert mathml to images in web pages. People are actually using these.

This article just made me angry. OH NO, I thought as loudly as possible. PEOPLE ARE WRONG ON THE INTERNET!

While people like Joe Clark decry the shortcomings of our tools, the rest of us are using these tools to get real world things done.

Also, the picture looks like a penis. Srsly.