Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
News

CSS for Mobile Devices 38

Death of Rats writes: "The World Wide Web Consortium has finally released its working draft for Cascading Stylesheets 2 for Mobile Devices. Definitely check this out if you intend on getting in on WAP or any other form of wireless internet."
This discussion has been archived. No new comments can be posted.

CSS for Mobile Devices

Comments Filter:
  • I haven't followed the development of CSS lately (the syntax of CSS is bloated and non-orthogonal - I wish we get something cleaner and better), but I thought CSS3 was to become modularized like XHTML, so I guess this is just a step in defining what is needed for small screen devices.

    I haven't bothered to look at WAP after I read the first spec. I don't trust the telecom companies to produce anything of value. Buzzwords and flawed 'standards' is what they are about.

    /mill
  • I thought it just looked like a shorter version of the CSS2 spec. I didn't see anything specific to mobile user agents.

    WAP is dead because both the idea and the implementation sucks. CSS' only sucks in its implementation.

    /mill
  • Linux Bios.
    Embedded Linux for the OS.
    Embedded QT for the desktop.
    Proper working palmtop browsers ( Using this CSS spec and a bunch of other things that aren't available yet ).

    Palm's future is a little doubtful but it's gona be fun to watch the fight. PalmOS with the installed base. LinuxEmded with the flexibility and extras. Wince ( Now Windows Powered ) with all those marketing dollars.

    The question is; Can MS PAY enough people to use that the network effects make it the default ?
  • You folks that replied to my initial post (and you who replied to those replies) -- y'all kick ass. This is the best series of replies and discussion that I've seen in ages on /. You guys should come out and play more often. :)

    Now I'm going to have a cheery day.

    -Waldo
  • Actually Amazon may be a bad example, as it works quite well with text mode browsers such as lynx
  • Quick! Someone port DeCSS for Mobile Devices!

    Remember, it's our right to watch DVD on whatever platform we want (even if it is crappy B&W 160x120 Palm displays)

    Al

  • "...a page designed with a CSS2 style sheet can have multiple media types, the cellphone section would describe how to render the page on a cellphone, while the browser sections would identify how to display it under a browser..."

    Um, will you at least put the "cellphone section" first, then... with an automatic cutoff that keeps the rest from flooding my bandwidth? ;^/

    The theory here was supposed to be that you have exactly one section, that's just rendered differently for each device. As a theory that's very elegant, but as an interface in the real world it's turning out, over and over, to be a hollow dream.

    McCluhan taught us in the sixties that the medium is the message-- you can't put the message in one file and the 'styling' in another. This problem with mobile devices and bandwidth is just the tip of the iceberg for CSS's fundamental wrongheadedness, imho.

    The right longterm solution, I've been arguing [robotwisdom.com] forever, is to embed the document's styles in exactly the way WordPerfect used to do it-- with codes for BOLD and ITALIC, etc. Display devices can render those however they choose.

    But in these earliest days of wireless, when every byte counts, the only way to go is optimised custom pages-- it shouldn't even be HTML, because the tags are too fat.

    And when the bandwidth improves enough to handle HTML, it will work best with the same basic HTML that lynx likes. CSS just never solves any real problem along this evolutionary path!

    I see this as just another top-down, ivory-tower W3C boondoggle, like XML [robotwisdom.com]. Those guys couldn't design a usable interface to save their lives-- look at how unreadable all their specs are! TimBL is the guy who thought up "aitch-tee-tee-pee-colon-slash-slash" for crying out loud...

  • Yeah, I've used the 'light' setting too, but I think it's still not well suited to mobile devices with small displays connected at 9600 bps. The 'home' page is just too long. A list of story subjects that link to a story abstract would be a better choice IMO.

    I'm not interested in all topics anyway so why shuld I wait for them to download?
  • Exactly. I can't understand why the W3C has drafted this as a seperate "standard" and not incorporated it as part of CSS. And for all intents and purposes, this could be just another set of implementation guidelines for CSS2, except:

    Sec. 4.7, The MP-UA is not required to satisfy the CSS2 conformance statement pertaining to the handheld media type
    You'll excuse me if I don't feel like digging up the relavent portion of the CSS2 spec (Sec. 7.3.1). But the point is, CSS2 and HTML4 were designed to be generic, implementation-neutral descriptors of content able to be applied to any type of display device. That's why there's a media attribute; so the standard doesn't have to be rewritten for some new media type, just outline the specifics for that implementation and wrap it with media="handheld" And if they thought that the current CSS2 implementation for handheld media was outdated, then update it. Not this divergent crap.
  • I guess this means we're all going to have to start mirroring this program [pigdog.org] now.
  • CSS support for browsers is weak enough, I can't imagine how bad it will be for mobile devices.

  • Now I can finally have the possibility of watching The Matrix on my BlueTooth device.

    HALLELUJAH!

  • I have to agree with this, it's almost right on the button. Here is the problem that I see:

    Many programmers are rushed to market. This contributes to the so called IT shortage. It's not a shortage of IT workers, but a shortage of competent workers.

    This brings along shoddy code and short sighted goals, many people program but do not understand many of the important underlying aspects of good code, like re-usability, de-coupling, and most importantly, and the point of this entire rant, separating content from code.

    I'm sure this causes lots of headache for people who create pages for Netscape, IE, Palm, etc. The problem is, many people approach this from the "Well, I'll make a version of each page for every browser" point of view. Of course, this isn't how the big boys do it, usually, and if people understood why then it wouldn't be a problem.

    If content providers understood this better, and perhaps coded in a way that the content was actually separated from the viewer, then they could provide their content in any way they need, from the web, to mail, to printed flyers, to anything really. The gloss really has little to do with the information, unless of course you are advertising your new high quality printers. :)

    Seems like this is just filling a hole for people who don't know any better.

  • when I first saw the headline I thought "Great, really crappy encryption for movile devices". Then I thought "why the MPAA would be interested in mobie devices?" At least when someone says Divx I know that they're at least talking about digital video.
  • First, of course it is a question of definition what is meant to implement CSS, level 1 or level 2. I would say though that Mozilla and Opera 4 supports CSS1. There are a couple issues before full CSS1 support can be crossed off as a done deal (Netscape 4.* sucks though). The remaining few issues [webreview.com] may annoy, but won't break any reasonable design.

    CSS2, unlike CSS1, is a huge standard. Full compliance is hard. Mozilla is almost there, followed by Opera, and IE not far behind. Even if most of CSS2 is implemented, the parts that are not are enough to make a web designer's job more difficult.

    CSS level 3 is slated [w3.org] to be even huger, but at least it has the decency to be modularized, and you don't have to implement all modules.

    CSS Mobile Profile breaks rank from the modularization in making a CSS2 light. The working draft is a clean subset of CSS2, if you support CSS2, you support this draft (as CSS level 1 and 2 were made with handheld devices in mind too). All it does is to say that it is OK for a handheld device not to support this and this and this CSS property.

    This is a bit of a non-event really, the title "Mobile Profile" makes you think that this is related to CC/PP [w3.org] capability negotiation, while in practice it is CSS2 with the hard bits left out.

  • Um, will you at least put the "cellphone section" first, then... with an automatic cutoff that keeps the rest from flooding my bandwidth? ;^/

    As it turns out, that's not a problem: most cellphone browsers wind up first sending a request to a special WAP server, which is connected to the internet, and from there on out everything is normal HTTP. Presumably, one would have this server pick up some of the parsing.

    And hey, I think XML is pretty cool - last year, my summer job was all about XML. Although the idea was to take an XML document you knew nothing about and allow people to do intelligent searches on the thing. Head on over to xfront.org [xfront.org] for more information about this.

    Actually, XML has one cool use - suppose that Slashdot generated the comments and all the pages in XML. So there would be a <comment> tag and so-on. Then, using XSLT [w3.org] you transform the XML document into HTML. That way, if you ever wanted to change the look, you just edit the XSLT, and everything changes to the new look. Unfortunately, that requires XML and XSLT parsers to be on the client-side. (Or you can do it server-side and watch Slashdot be crushed under the load.)

    When you get right down to it, XML is really just the SGML spec reimplemented with certain pieces removed. The pieces they removed actually makes it easier to parse - but there's no way to understand what an XML document actually means. (Which was what I was supposed to solve.) XML Schemas [w3.org] are supposed to help this in some way. The thing XML is really useful for, though, is simply having a standardized way of formatting data, so any parser can read it in. Then an application needs to know enough about the document to determine what it means. In that way, XML is really just a flat-file database, which happens to look like SGML.

  • ...that the key to getting designers to adhere to standards, is consumer awareness. If the average cell phone buyer knew that support for CSS can SIGNIFIGANTLY increase the quality and ease of use of his/her online experience, they would demand vendors carry standard compliant devices. Much the same way Dolby certifies amplifiers with the Prologic tag.

    CSS really kicks some butt, and it gives designers an extra tool to make those damn tiny screens one step closer to functional.
  • Wouldn't it be nice... but there ain't a chance in hell that this'll ever be used, at least any time before it becomes completely obsolete. There isn't even any support for WMLScript which has been part of the standard for months and months now. Nobody's implementing the latest standards, and nobody's using the latest implementations. Besides, if you want to support the devices that exist today, this is just another thing to port to...
  • After looking over the draft, the only thing I can summarize on is that it looks like some group trying to put rules and regulations on something that really doesn't need it or want it for that matter.
    I try not to be pessimistic, but I can't understand why this would be necessary in order to have mobile Internet devices available.

    My 2c
    --

    Vote Homer Simpson for President!

  • It seems to be things that increase the viewable area. Like not allowing CSS definitions of 'empty-cells', 'line-height', and also somethings that disallow layering and DHTML like not having 'z-index'. It seems that implementing this shoddy level of CSS on a WAP device wouldn't be too difficult (remember that most WAPs are like fixed width terminals onscreen - they have little need for changing of line-height).

    Regardless however they're going about it the wrong way. Making another CSS definition because the W3C think they know that you don't want an optional 'text-shadow' for a title -- it's condescending to current-day display technology that has made ground in recent years in regards to dotpitch, resolution, and of course colours.

    I hope browser makers rebel against this shitty standard and support the full CSS spec.

    WAP 1.0 sucks arse, WAP 2.0 is XHTML, which is a little better. Does anyone not like WAP2?

  • I am inclined to agree. There is the possibility that W3 is going somewhere with this, or that in the future as handhelds progress this will become more useful. But for now, its not. Still, if people <I>do</I> implement it, its better they do it to standards than fuck up like the browser companies did. I guess its just something to keep in mind if you are making wireless software with the J2ME
  • for a real os go to: freebsd.org
    be sure to stick it on your crackpilot.
    then go wach DVD's even though the MPAA, want to strangle you now
    (stick a long hard baseball bat with no vascoline up it's but wraped in barbed wire)
  • Why on earth is everybody worrying about trying to support CSS on the current generation of mobile phones? The screen's too small and the lack of a halfway usable input device too restrictive. There is at least one way of getting decent mobile Internet access already. I've been running Opera for EPOC (the 4.0 beta) on my Psion netBook for a while. Through a Dacom PCMCIA modem it works at about 150% the speed of IE on my laptop. Through the wireless card I've just got I can wander anywhere in my house, or down to the river below, and access the Net through my LAN at up to 2MBPS. Opera supports all the relevant standards, including CSS, and sticks to them. See http://www.opera.com/epoc/whitepaper.html for details. It's small, and it's - relatively - stable. Hell, I'm actually beginning to appreciate the Symbian hype.
  • Why would we need CSS for wireless devices?

    The great part about WAP as it is nonw, is that it is 100% information, with no bullshit. Just like the 'normal web' used to be.
    Text-only and on some pages a simple image.
    Why? Because:
    1) You have a very small screen
    2) There isn't much bandwidth (9600bps is default)

    With WAP, there are no blinking items, there is no irritating sound.
    Why do many peoply hate Flash-websites? Because they're annoying; because they load very slowly; because many browser-functions aren't possible to be used with Flash.

    On a wireless device, why should we want a background color? Or even a background image?
    Try having a 2-bit background image (black/white), and use one of those colors as the text color. Unreadable.
    Mobile phones with color screens are unaffordable for most people. And when you have a handheld pc, you don't need WAP because you can have real html.

    Borders are nice. I see one surrounding this text box, and I see one surrounding buttons; windows; almost every object on my screen has a border.
    But I have a 15" monitor, with many objects on it. On my 1" phone-screen, I have one border (the screen border itself) and that is more than enough.

    The funniest item is 'Cursor'.
    Phones do not have a cursor and pda's and handheld pc's use a stylus, so no cursor either.

    Text-Shadow. Nice. But why? Aren't b, i, u, big and strong enough markup?

    I seriously doubt if CSS is needed for WAP.
    Many people forget that the larger devices can handle html.

    For those who still don't get my point: A nokia 7110 WAP Phone (the most used WAP phone) has 96-pixels wide screen. - http://www.wapsilon.com/ - Web-based WAP Browser
  • Filtering content will never adequately address the fact that the handheld device is different and requires different UE, different structuring of the content,... I'm not going to read the Atlantic Monthly on my cell phone no matter how you filter it. Nor is Datek's streamer the way I want to see stock quotes on my phone. For stuff you want on a mobile device, you need to redesign how it is delivered to suit the features and limitations of the mobile device.

    As for the foolishness of doing much with layout on a mobile device -- that is, in a sense, one motivation for subletting CSS for mobile devices. The idea of CSS is to separate the formatting from the content. There is still formatting that has to be applied to content aimed at a mobile device, CSSMP is an attempt to describe what is possible and appropriate.

    Sooner or later WAP will be rendered obsolete by changes in the wireless networks. But WML and WMLScript will probably endure longer than WAP just because cruft never dies, and this is useful cruft. I think the W3C is right to look forward to a post WAP mobile era where variations of familiar standards, such as XHTML Basic and maybe CSSMP, will integrate mobile devices into the web more cleanly than WAP.

  • The other alternative is to do it all on the server using XML to specify your content and XSL to do the transformation. It exists, it works, and it doesn't rely on hardware manufacturers implementing new standards properly.

    I can't see that, in the near future, anybody will want the same style sheet for a desk top browser and a mobile phone - and I would expect the content displayed on a phone to be very much more restricted. Rather than send a lot of data that's going to get ignored, there's a good argument for only serving the data that's required. A producer->processor->formatter architecture allows for this. A servlet generates dynamic content, which is then passed to a processor that mungs it about a bit - inserts dates, side bars, menus and the like, before a formatter turns it into, for example, HTML, WAP, VoxML, or a binary format like PDF. Apache Cocoon [apache.org] is one architecture that does this, now.

  • If a cell phone can display CSS, why can't my PC? Let's get our priorities straight.
  • On a related subject, isn't it time for a Slashdot HTML 'view' formatted especially for small screen low-bandwidth devices? I know you can do a lot by setting your display preferences, but it could be a lot better.

    On the subject of WAP: I know the /. consensus is that it sucks, but a WAP version of Slashdot would definitely be welcomed by (admittedly non US) readers. WAP may suck, but the phones are cheap and capable enough to read headers and article abstracts when you're wasting your time in a queue or something. I wouldn't want to take part in a discussion typing on a phone, though...

    WML pages are easy to implement too, I think I could do a reasonable WAP version in a day or so.
  • I guess I'm too politically infected. The first thing that came to my mind after reading the story is, "So when will DeCSS arrive for Mobile Devices??"
  • Pigdog DeCSS [pigdog.org] is a filter that removes CSS-2 from a web page.
  • The other alternative is to do it all on the server

    My web host doesn't have CGI support. Heck, I can't even do 301/302 redirects; I have to use meta tags or EcmaScript. How do I do anything on the server?

  • I guess I'm of the school of thought that the ISPs for mobile devices ought to filter the content and rewrite it to suit mobile phones.

    Huh?! Last time I checked, my ISP was responsible for providing me bandwidth and...well, bandwidth.

    Try to think of one reason why many destinations (gobs of ISPs) should try to filter the immense variety of web content, instead of each "content provider," who has easy access to the data, creating output viewable on numerous devices (once, mind you, not once/transfer), before it is in transit.

    The idea of rewriting code (ie, http://www.amazon.com/phone/) for different access devices has always struck me as somewhat foolish.

    Yeah, different devices, like say, IE and Netscape? It may be inconvenient for web developers to do so, but hopefully standards like this will decrease the likelihood of a dominant proprietary system.

    Tom

  • Is anyone using WAP? It'll probably be a while before CSS gets supported, and even longer before it gets implemented. Even browsers running on PC's don't all support it(or support it in the standard way). I don't think the idea of browsing stuff on a dodgy screen is going to take off anyway.
  • We can credit W3C for being forward-looking, but I expect that CSSMP will go the way of WAP.

    Perhaps not. I believe the point [useit.com] of this newly crafted subset of CSS2 [w3.org] is to provide a stable reference for useful functions that ought to be in mobile devices (meaning ultra-portable devices [nokiausa.com] with limited display capabilities, and not meaning laptops which might have better display capabilities [buy.com] than many quite old desktop computer layouts with small VGA monitors which are still in use throughout the world).

    This area is of keen interest to me, and after the long agony [lycos.com] with simple HTML 3.2 [w3.org]/4.0[1]+ [w3.org] and with CSS1 [w3.org] through the still not-quite-totally-there CSS2 [mozilla.org], any way to avoid any more standards wrangling will come as a great relief to those of us who have to actually do this stuff [about.com] for a living. I'd imagine that XSLT 1.0+ [w3.org] engines [xmlsoftware.com] will do much of the actual work, and it really helps to be able to more or less reuse all that existing work with a near-exact subset of CSS2.

    Anyways, I'm back (in a few minutes, after a little more procrastination) to figuring out how to most efficiently split up parts of (simple for now) XML [xml.com] documents for later Java [apache.org]/Python [fourthought.com] XML/XSLT processing [amazon.com], while allowing simpler, more immediate PHP 4.0+ [php.net] XML processing. Argh ....

  • by waldoj ( 8229 ) <waldo AT jaquith DOT org> on Friday October 13, 2000 @09:26PM (#706972) Homepage Journal
    It seems strange to me that a wholly different version of CSS is required for mobile phones. Wouldn't an extension of the existing CSS definitions make more sense? The majority of these terms exist in CSS.

    I guess I'm of the school of thought that the ISPs for mobile devices ought to filter the content and rewrite it to suit mobile phones. The idea of rewriting code (ie, http://www.amazon.com/phone/ [amazon.com]) for different access devices has always struck me as somewhat foolish.

    Perhaps the only thing more foolish than that is attempting much in the way of layout on a PCS screen. :) I understand that there are more advanced devices, like the Palm VII, that can handle more than 16x3 characters (or whatever), but it still seems to be mostly about content right now.

    We can credit W3C for being forward-looking, but I expect that CSSMP will go the way of WAP.

    -Waldo
  • by _xeno_ ( 155264 ) on Friday October 13, 2000 @11:24PM (#706973) Homepage Journal
    It is an extension of CSS2. CSS2 has this concept of media types, with different rules. (For example, there is a vocal media type, which has very little use for line-height and rendering things... The one thing I remember about the voice media type is that you can specify types of voices to say (render) content in.)

    All CSSMP does is say that there is now a mobil-phone media type, and that these rules are used for it. In a way, it's a completely different spec, but you'd need it to be separate. Lumping voice browsers, TV browsers, and console-browsers into one standard would get... messy. CSSMP just gives another set of rules for rendering HTML content.

    BTW, how do you expect ISP's to rewrite Amazon.com [amazon.com]'s main page to work on a cellphone? It's kinda graphically intensive... How about Slashdot? For simple pages, it'd be easy, but for complex pages like Slashdot it would be all but impossible. (Especially pages that are designed to look a certain way, which cellphones, and lynx, usually choke on. Try nVidia's webpage [nvidia.com] under Lynx some time - it's all graphics without ALT tags.)

    Actually, as it turns out, CSSMP might be exactly what you want - since a page designed with a CSS2 style sheet can have multiple media types, the cellphone section would describe how to render the page on a cellphone, while the browser sections would identify how to display it under a browser. A properly designed page would work both under a CSS2 compliant browser (there aren't any!) and under a CSS2 compliant cellphone (and... there aren't any of those, either). But it would be the same HTML document, just different styling rules for different ways of displaying the same content.

    And while you're giving the W3C credit for being forward looking, realize that there is no (finished, I think Mozilla trys to) browser that currently implements CSS2 - and the W3C is currently working on CSS3 [w3.org].

  • by _xeno_ ( 155264 ) on Friday October 13, 2000 @10:20PM (#706974) Homepage Journal
    Given that the only browser that I'm aware of this date that even attempts to implement CSS2 (which is not the same as standard CSS which IE for Mac does right) is Mozilla. (Or, rather, Gecko, I guess. The Mozilla renderer/parser combo, which I think is Gecko - but I might be wrong... Bottom line is that all Mozilla based browsers (eg, Galeon) should pick up the ability.)

    There is currently one production browser in existance that actually implements CSS1 - Internet Explorer 5 for Macintosh. Only the Mac version of IE does CSS1 correctly. No other browsers do. This spec is designed to supplement CSS2. The W3C is actively working on CSS3 for some strange reason...

    As to why they did this, that's simple: HTML was never designed to specify the style of the document, just the structure. That's why the tags have names like Paragraph, Emphasis, and Strong. HTML was designed to structure content - it never was intended to be used to create the complex web pages we see today.

    CSS was designed to solve that problem - it would move style away from the structure. CSS2 has the idea of multiple media types - all this mobile phone implementation really does is add another media type. The idea behind media types is so that HTML+CSS2 can be used in both a browser, and then have a special set of rules for when it's printed. There's a "vocal" set of rules for blind people who use text-to-speech browsers. Now there's a WAP "media" type so that phones that support it can view content.

    Most simply, the idea behind CSS2 is to allow someone to create a webpage based on content and not on style - and to allow the CSS backend to be changed, so that the look and feel of a website isn't done in HTML as much as it's done in CSS. The mobile phone CSS spec is simply an extension of this ideal - to separate content from style. By extension, that means you don't need to rewrite the page in HDML - all you need to do is use the special cellphone CSS section, and the page is "converted." This was the basic goal behind CSS2. It's too bad no one ever really got around to using it.

A penny saved is a penny to squander. -- Ambrose Bierce

Working...