Re: [WSG] Site Review: testdrive.fueladvance.com
On 22 Mar 2005, at 23:34, Tatham Oddie wrote: All, Without out taking up too much of your time, it’d be great if you could take a look at http://testdrive.fueladvance.com/ and let me know anything that leaps in your face as bad. Please be brutal. (PS. Notice the XHTML1.1 validating ASP.NET? J) Non validating. You have a "" in your supposedly validating XML document. You should check the w3c media type recommendations as you are sending your document as text/html and it shouldn't be. Perhaps you should try HTML 4.01 Strict. -- Paul Connolley - http://shunuk.co.uk/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] " or " in copy?
Additionally: Taken from http://www.w3.org/TR/REC-html40/intro/sgmltut.html which is an overview of looking at SGML Content model definitions The content model describes what may be contained by an instance of an element type. Content model definitions may include: • The names of allowed or forbidden element types (e.g., the UL element contains instances of the LI element type, and the P element type may not contain other P elements). • DTD entities (e.g., the LABEL element contains instances of the "%inline;" parameter entity). • Document text (indicated by the SGML construct "#PCDATA"). Text may contain character references. Recall that these begin with & and end with a semicolon (e.g., "Hergé's adventures of Tintin" contains the character entity reference for the "e acute" character). Emphasis on "Document text" - PCDATA. Text **may** contain character references. This doesn't imply that all of the four main html entities have to be encoded (<, >, &, and "). Note this document originally applied to HTML but is as relevant to XHTML if you please. The only important consideration is that ampersands be encoded correctly in HTML and XHTML. -- Paul Connolley - http://shunuk.co.uk/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] " or " in copy?
(BOn 16 Feb 2005, at 22:16, Dmitry Baranovskiy wrote: (B (B> Actually " is an inch symbol. For quotes we should use “ and (B> ” in normal text. (B $B!m(B - The double prime. U+2033. The inch $B!l(B - The prime. U+2032. The foot (Bhttp://mathworld.wolfram.com/DoublePrime.html (B (B>> Taken from http://www.w3.org/TR/html4/sgml/entities.html (quote level (B>> altered) (B>> > ISOtech --> (B>> > U+2033 ISOtech --> (B (B" - The double quote (straight/neutral) (B' - The apostrophe or single quote (B (BThere are also the obvious left & right, double & single quotes (B (B>> > U+0022 ISOnum --> (B (B-- (BPaul Connolley - http://shunuk.co.uk/ (B (B** (BThe discussion list for http://webstandardsgroup.org/ (B (B See http://webstandardsgroup.org/mail/guidelines.cfm (B for some hints on posting to the list & getting help (B**
Re: [WSG] Re: XHTML Strict alternative to
On 9 Feb 2005, at 00:49, Geoff Deering wrote: Patrick H. Lauke wrote: There are *no* inherent benefits to tableless, css driven layouts in XHTML strict versus tableless, css driven HTML (strict or transitional) or even XHTML transitional. That is a misconception. Provided the XHTML document has been "extended" and that the correct content-type header has been sent for the document (application/x…) there are *no* benefits. Pages don't load faster because no current browser will incrementally load the page. Mozilla themselves even recommend that you do *not* send it as application/xhtml+xml because of the slower rendering. With a HTML document (strict or otherwise) the rendering occurs incrementally There are differences to the way a rendering parsing engine will work with the different doctypes. No. There are differences in the way things such as box models are handled and the like. This is to do with Quirks mode and not to do with benefits of XHTML strict over HTML strict. That's also why this list exists, because, from what I can see is that most of us need a list like this so that we can deal with the bugs that are in the parsers and rendering engines. If you think that this list will deal with parsing and rendering bugs you are probably mistaken. You could probably discuss them and talk by all means but the real work gets done when you submit bug reports to bugzilla and the like. But I'm also talking about working with bug free parsers, even if that is in the future.In that case there is quite a bit of difference with the way a parser will work with the same design in Strict as it will in Transitional. Considering that Internet Explorer are reported to have said that they didn't want to change the IE engine because it would 'break the WWW' and also considering that Mozilla even chose to *have* a quirks mode I think that you will see the existence of quirks mode for a long time to come. But it makes no sense to use Transitional where Strict does exactly the same job. Reverse this statement and realise that it means nothing. In particular, when served as text/html rather than application/xhtml+xml, and when not mixing in additional "X" technologies, for all intents and purposes XHTML is simply HTML with a slightly funkier syntax (self-closing elements for instance) which older browsers treat like broken HTML. There is no added benefit to the user. All the things you mention (switching stylesheets for different layouts, etc) can be done fine in transitional. You are missing my point completely. Try maintaining or redesigning large content sites that need to meet web and accessibility standards that are caught in this dilemma. I have seen some real messes in my short time and I know that HTML transitional can be just as accessible as XHTML strict. All the elements available to XHTML strict are available in HTML transitional. A perfectly validating XHTML strict document has just as much chance to be inaccessible as a HTML transitional. Try creating an XHTML Strict document which validates and then convert it to a HTML document (by removing the forward slashes from self-closing elements) and then change the DTD to HTML transitional. Open both in a text only browser and compare them. If you see any differences then let me know. I really see it as something basic that web developers who take accessibility and web standards as their core approach would understand that to redesign sites that meet valid strict (either HTML or XHTML), are much easier to rework than Transitional. Once again you are saying that a HTML transitional document can't contain all the same elements as an XHTML strict document. Please explain why you would use a transitional DTD where a Strict one is valid and works just as well? As before, reverse the two subjects and see that the statement is still true: "Please explain why you would use a Strict DTD where a transitional one is valid and works just as well?" -- Paul Connolley AccessPlanIT – LWDP Data Manager Phone – 01524 389541, Email – [EMAIL PROTECTED] ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Building with scaling in mind
On 28 Jan 2005, at 00:22, Paul Novitski wrote: At 01:30 PM 1/27/2005, Tom Livingston wrote: I was admiring stopdesign.com. I think it's a beautiful layout. But I am having a problem wrapping my head around the concept behind building a page like that so that when text is scaled, the containers don't get all messed up. On stopdesign.com, the containers get deeper as needed but the layout (i.e, the positions of one container next to another) stays solid. Tom, Looks like stopdesign is using fixed width containers, so when the text enlarges the page stretches vertically but not horizontally. You need to check the various layouts that he uses. There is an option to change the style to Liquid Bleach (I think). You will find that he does have a fluid layout. You just have to enable it. http://stopdesign.com/about/prefs/ There you go -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Can I use a table in a form?
I missed a bit of text On 13 Jan 2005, at 18:18, Paul Connolley wrote: If I can possibly allow you to stretch your imaginations for a moment. Imagine me presenting you with a set of axes on some graph paper for a line/scatter plot and asking you to put your information onto it. It just wouldn't happen would it. It seems extreme but I wish you to consider how you collect information. There are only several situations in which you would have a table layout for data input. If the information is predominantly numeric. Classroom and workplace rosters often have rows and columns for each student/employee. This is common in other recurring data collation methods. This is where the information is accumulated over time and it is quite simple to follow one row by the next. I think you should consider how usable the form would be if it were a huge table of inputs. Scary. I'd personally click back to google and find a better website. One where I wouldn't have to register so much information. I'm not sure what information is being collected but can you justify storing named data about so many people? Data protection is quintessential. Is it necessary to find out so much. This seems to be the most usable method. The HTML specification gives you several elements for data separation and input. The fieldset, form, legend, label, input and textarea elements. You could create a simple grid layout with CSS if you really couldn't implement a better form method but I'd say that one or two individuals per page would be better. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Can I use a table in a form?
On 13 Jan 2005, at 16:47, Kornel Lesinski wrote: The point is that it is not layout table. Well, to be pedantic, a table is all about layout. Layout of information. It has semantic value. I really hate that statement. It's a kind of table that can have summary, caption, headers and contains repeating sets of data. Data (n.) - The plural of datum meaning information (lat. "something given") Everything is data. Even a list is data. Because it is not *tabular* data, unlike the practicular form that this discussion is all about. Forms are about collation of information. For a second, I'd like people to stop thinking about HTML and consider the world of paper which still exists. As a student of statistics I had to collect information (data collation as my lecturer would put it of occasion) and analyse it. To collate the information I had to create a questionnaire. It would consist of a series of questions followed by answers. Upon finishing my analysis I would then open up a spreadsheet and type up the results. In order to qualify as passing, standard scientific form had to be followed. At no point did I use a table for anything other than a result. Processed information. If I can possibly allow you to stretch your imaginations for a moment. Imagine me presenting you with a set of axes on some graph paper for a line/scatter plot and asking you to put your information onto it. It just wouldn't happen would it. I would almost think you'd want to deal with each traveler separately, one at a time, in some sort of paged form. For instance, if I fill out the initial part of the form and indicate 5 travelers to be insured, the form would be submitted, the initial form fields temporarily stored, and then the next form presented with fields for traveler 1. Once that is filled and submitted, on to traveler two. This seems to be the most usable method. -- Paul Connolley -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Still need help with the list style
On 3 Jan 2005, at 22:38, Paul Connolley wrote: Notwithstanding any bugs in the browsers, that is. Which is the problem anyway. Specifying a list item element to have display : block means that no glyph should be rendered and that it should be just a box. Being overly explicit is for the benefit of IE and, possibly, Opera. -- Paul Connolley - http://shunuk.co.uk/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Still need help with the list style
On 3 Jan 2005, at 21:53, Ted Drake wrote:
#rlcategories li {list-style:none !important; margin:0; padding:0;
display:block;}
Try using list-style-type : none as opposed to the shorthand property
which expects three values.
!important may, and should, not be necessary if you have used logical
and sensible application of CSS.
With regards to your XHTML:
There are two problems which can be solved in seconds. The img element
needs to be self closed. The javascript needs to be commented out in
some way or loaded externally. I recommend loading it externally.
With regards to Charles Martin's comment:
Try applying the list-item-style property to the UL element. I had
this problem before and it seems to prefer this option apply to the
whole list and not just a single LI element.
Note that the CSS specification indicates that list-style-type
Applies to: elements with 'display: list-item'
http://www.w3.org/TR/REC-CSS2/generate.html#lists
and
http://www.w3.org/TR/CSS21/generate.html#lists
I don't know how this will affect you but it is worth remembering that
unordered list element is the block level element and that the list
item element is the list element. Whilst inheritance seems to fix your
problem, adherence to the specifications would or should be advised.
Notwithstanding any bugs in the browsers, that is.
--
Paul Connolley
SQL/Systems Programmer
Egocentric - http://egocentric.co.uk
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] FOUC in Safari was Slow loading of CSS
On 3 Jan 2005, at 13:43, Lea de Groot wrote: On Mon, 3 Jan 2005 14:20:02 +0100, Roger Johansson wrote: Safari? I use it all the time, 10-15 hours a day, and I can't remember ever seeing a FOUC in Safari.[snip] Hmmm, interesting - I'm running Panther, so I'm not running an early version - 1.2.4 (v125.12) Anyone else running Safari seeing this? I can also confirm that my PB G4 with 10.3.7 running Safari 1.2.4 (v125.12) doesn't encounter the FOUC at all. I have never seen one since my college days running IE 5.5 -- Paul Connolley - http://shunuk.co.uk/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] The Holy Grail ... CSS Liquid Three-Column Layout
On 17 Dec 2004, at 03:29, Hugh Todd wrote: Anyone come up with, or implemented, a 3-column layout of this sort in which the left and right columns also stretch as a percentage of the page width? I refer you to Zoe Gillenwater (http://www.communitymx.com/content/article.cfm?page=1&cid=AFC58). I am surprised that she hasn't made comment. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] x-browser javascript: is this OT?
On 14 Dec 2004, at 23:10, Barry Beattie wrote: we're building a large web app where JS is vital to make it work. Things like modal "windows", tabbed data entry forms, RPC data exchange with xmlhttprequest, xml manip within the page, etc. [snip] Trying to run it on NN4, PDA's and mobile devices just won't happen, I'm afraid. I see that you mention xmlhttprequest. With note to this wonderful pseudo-standard, I believe that you should take care not to abuse it. The possibilities of this method are wonderfully endless but it should not, at this stage, be used to circumnavigate the submit button. Use it for all your needs, but remember the other browsers. Imagine a test case, if you will, where you wish to present several select box* with topic followed by sub-topic etc. By using xmlhttprequest you could streamline the results for the following select box and so on. This would allow for a greater usability experience for certain users. To maintain a "backwards compatibility" you would still offer all of the choices initially so that a user of a "less capable" browser would still be able to follow along. The alternative would be to allow a user to submit through each topic and subtopic with the select elements appearing after each post operation. I hope that wasn't too in-depth. *The select element in html which allows a single/multiple choice selection -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Using in a
Angus wrote: I have a line of text placed in a / that I would like to shrink. Can I use /? if so, how? … would do the trick. I would, however, like to clarify that the small element is described (in the w3 markup reference) for things such as "small-print" and other such items. I believe you should consider why you are deciding to make the content smaller. Is it necessary? If you can say yes then carry on, otherwise I would probably follow a method similar to Nick. Natalie wrote: I believe is valid in HTML 4 but cannot find reference in XHTML at all. The easiest way to check is to open the DTD that is referenced in your doctype declaration and search for the word small. It will likely direct you to a line like this: -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Site Critique
On 12 Nov 2004, at 12:33, Laurie Keith wrote: If any of you busy people have a spare 15 minutes, can you give me an honest evaluation on our new corporate web site. 15 minutes spent so here goes: http://www.createwith.com http://with.shunuk.co.uk It is just a simple mock-up but I wanted to show you the point which Susan, Sam and Veine have made. It truly is that easy to create something like this. Veine made the point that it lacks graphics. Whilst I partially agree, I don't think this is your main concern. The content is really your key here and you should be presenting it in the best way possible. I'm not saying you shouldn't ever use flash, but use it when needs require. Flash shouldn't be needed for a website navigation system or even for text content. Branding is always a corporate issue. The company i work for also chose a minimalist design so don't be frightened of those plain white web-sites they really do work. Our main company web-site and stationary received praise for having courage to accept that minimalist designs can be visually stunning and aesthetically pleasing. with™ : people who create business effective communication with you This (taken from your source code) needs trimming down, and ID="title" removed. To return back to the point about flash. I notice you are loading a lot of external flash anyway. This should be easily integrated into an ordinary page with alternative content available. The maps are a nice touch. Alternative content could be something as simple as a link to the multimap page with the same map. I agree with Susan with regards to the about page being the main entry. Whilst it is handy to offer some information _about_ the company, what is needed is some real content to interest the visitor and give them a general overview of what you really do. Plus, marquespeak doesn't always gel with people. "Deliver business effective communication" sounds delicious but I had to think thrice to understand it. I'm not saying "pretend you're writing for a nursery class" but take consideration that not everyone understands it. To go to the extreme, dyslexia is a language difficulty which isn't actually a "thick-persons-disease" (my esteemed friend is a terrible dyslexic but he has a BA (hons), MA and is now heading off to be political) but appears in many walks of life. In tech-speak what i just said was, "don't shullbit a shullbitter". I'd comment more but I'm sure there are others who will offer other tidbits of info. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] problems in Firefox and Opera
Erietta Sapounakis wrote:
Hey there everyone
Hi Erietta
[snip]
#detail-tile ul {margin-top:1em;}
#detail-tile li {list-style-type:circle; display:block;
list-style-position:inside;}
[snip]
...[snip rest]
Ultimately the problem lies within in your li statement:
display:block.
For a browser to render a list, the elements must be considered to be a
"list-item" (thus, display : list-item). MSIE is erroneously displaying
the circle bullets. I understand what you are trying to do but I
recommend taking another route towards implementing it. Do you have a
URI which I can look at in order to see it in context. I could better
offer advice this way.
--
Paul Connolley
SQL/Systems Programmer
Egocentric - http://egocentric.co.uk
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Semantics of Breadcrumb "you are here" links
Ryan Nichols wrote: Really a browser doesn't understand what any of the tags are. What you see are only the browsers default behavior at rendering certain items it's aware of in the DTD. A browser doesn't understand of course. It parses. Behaviour is programmed in HTML user agents. This was all put in by whoever made the browser, and is totally up to the browser. Default renderings are not specified in W3C. "This style sheet describes the typical formatting of all HTML 4.0 ([HTML40]) elements based on extensive research into current UA practice. Developers are encouraged to use it as a default style sheet in their implementations." [http://www.w3.org/TR/REC-CSS2/sample.html] Whilst it is just an "encouragement" it is worth mentioning as it has some bearing on the renderings of various browsers. The old way is to code your markup to the browser default behavior, really we need to code and markup to the content, semantically, then use the tools we have to tell the browser how to render. I agree that we should code well without writing at the expense of semantics. Too many HTML documents are a mish-mash of spans and divs. We should try our best to work with the elements which we have. Don't forget (this isn't aimed directly, but generally), CSS is there to aid a HTML document visually; not all people are *viewing* a HTML document. This is why good structure is essential and is of higher importance - IMO - than styling. I always found that the more I think in terms of the future and the way things are heading, it helps me make better decisions on what to do now. My preferred method is looking at how I can make the experience flow the best for the least privileged visitor, and then I improve from there. But I'm a usability and accessibility man, which is the plain vanilla ice cream to the choc chip css. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG]
Patrick H. Lauke wrote: Paul Connolley wrote: This is a perfectly natural English language grammar. Sorry, wasn't advocating changing the writing style, but having a mechanism in place to unequivocally tie a CITE course to Q or BLOCKQUOTE My apologies also if I came across wrong. I agree with you wholeheartedly. I just wanted to add my 2 eurocents worth and expand a little on things I thought may be of interest (like the direction which the XHTML 2 WG is taking with some of the attributes becoming elements) -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG]
On 22 Oct 2004, at 02:23, Paul Connolley wrote: [snip] consider the scenario of a screenreader user who skips from paragraph to paragraph, and ends up on the second paragraph of this [snip a whole load more] I'll reiterate that I see that I reiterated nothing. I've missed a bit out that I intended to write. I won't bother with a correction, I hope I passed some of my points across. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG]
Patrick H. Lauke wrote: [snip] consider the scenario of a screenreader user who skips from paragraph to paragraph, and ends up on the second paragraph of this Harry S. Truman said, The buck stops here. ... He then also said something else entirely. Now, assuming that the screenreader flags up that "something else entirely" is actually a quote, it still can't (programmatically) determine what source it's being cited from. I understand where you are coming from but I believe it is a bad example. To me, the above would look like: Harry S Truman said, "the buck stops here." He then also said, "something else entirely." This is a perfectly natural English language grammar. Of course writing for web isn't the same as print but sometimes things do pass across. If someone is skipping paragraph to paragraph they are likely to lose a little plot. I do like the way XHTML 2 is going with the quoting and citing. The user will, if interested, start reading around the element, but still not find out who the quote is from, and will have to - in the worst case - read the entire document top to bottom until stumbling across the . See above. I'll reiterate that sometimes meta-information can sometimes invalidate good written grammar. In certain contexts, all people should read entire documents. If I encounter a personal pronoun within a text, I have to occasionally read back a few lines. Of course this is made even more difficult by the actual citation. Harry Truman is the source of the quote above, whereas it is likely to be a html or other document in most situations. I am not a user of a screen reader so would welcome any input on how they handle reading section by section. Do they have a function which will take them back a few sentences? I believe that a document design needs to stay focussed on the fact that some elements of a document shouldn't be hidden behind-the-scenes whilst some should (eg. the summary attribute now promoted to an element in the last XHTML 2.0 draft I read). I should stop now because this is the sort of thing to be taken to the XHTML 2 WG list. Admittedly, you may not encounter this type of scenario often, and it's maybe an extreme case I'm talking about, but still...something that just nags at me ;) I am also nagged by the lack of ability that UAs give for handling the cite attribute in blockquote and q elements. There are ways of presenting the information but it is limited to non-ie browsers in most cases. It's a hard decision because, I don't aim to alienate my readers too much, but I do want the freedom to present attractive information to browsers which can handle it. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Short way to change background colors on CSS sheet?
On 14 Oct 2004, at 00:06, Lyn Patterson wrote:
#meetings#container {background-color: #ddd;} to the CSS .
You will find that adding a space between the two items #meetings
#container will hit the spot. They are two distinctly separate items.
Summarily, it means: an element named "container" within an element
named "meetings" will have a background colour of darkgreyish.
Then I added just under the tag in the
HTML which is probably wrong as it didn't work so how do I add the
unique id to each page mark-up?
With each page, you should name it with a different name and use it in
the id attribute (). Within your CSS, you
can refer to the id with: #newnameforthispage.
--
Paul Connolley
SQL/Systems Programmer
Egocentric - http://egocentric.co.uk
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**
Re: [WSG] Mac Tools Kit for Web Standards Developer
Kevin Futter wrote: SubethaEdit is impressive, especially given that it's free, and it comes with a bunch of preset 'pretty print' modules for code colouring in a number of syntaxes.[snip] Paul Connolley wrote: Transmit is quite nice but is as good an FTP client as Fugu or Cyberduck. [snipped me (paul) on about SEE] Kevin Futter wrote: True, but try doing a site-wide, 200-page find-and-replace with a text-editor; or move a dependent file to a new directory and have the software automatically update all dependent links in all pages ... Anyway, I fully appreciate that we all have our various ways of working! Indeed, I find myself to be a bit of a die-hard when it comes to unix and I'd be a grep man for that. Of course I'm a masochist so it follows quite easily really. Project management tools are one of those things that I dream about but never find myself comfortable with. YMMV as always. I agree with you that a GUI is much easier when looking at results. *cough* except when I'm reading my SQL web-stats in raw mode. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Mac Tools Kit for Web Standards Developer
On 11 Oct 2004, at 00:54, Kevin Futter wrote: SubethaEdit is impressive, especially given that it's free, and it comes with a bunch of preset 'pretty print' modules for code colouring in a number of syntaxes. By the way Kristof, I use Transmit too, but unlike you I think it sucks, and is poor in comparison to things like WS_FTP on Windows. Transmit is quite nice but is as good an FTP client as Fugu or Cyberduck. Combine this with the fact that they both work with SEE (SubEthaEdit), in that it combines SFTP functions with the editor, I don't need a website management program. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Is XHTML harmful?
Geoff Deering wrote: I am talking about CSS applied to HTML and the rendering of the CSS as applied to the parsing of the document. But still, strictly speaking, an XML based document is bound to be more semantically correct because it is well formed. This means that the CSS can be applied without fear of the parser misunderstanding where a declaration could have finished. [Snip] Paul Connolley wrote: You are talking about two distinctly different parsers. XHTML is a XML subset, HTML is an SGML subset. For example: [Snip example] In HTML it will not. With the SGML parser it knows that when it arrives at a new it is the beginning of a new list item. The same would apply, for example, to a paragraph. [Snip] You shouldn't try to argue about parsing when they are parsed by two different types of engines. But that is entirely my point. No. Your points: - Rendering of CSS when applied to a document - XML being more semantic because it is well formed - Parsers misunderstanding element declarations Well-formedness is, in this context, a XML concept. A SGML document (hence a HTML) is well formed whether you omit an end tag or not. I repeat, an SGML parser will not be confused when presented by two paragraphs which are not closed yet adjacent. CSS rules follow almost entirely exactly apart from a number of exceptions. This is what I believe you were referring to. It is wrong to confuse people about missing end tags as it is not the issue when it comes to rendering CSS. I'm a huge advocate of XHTML. I use it everyday in semantic design but I never tell anyone that HTML is less semantic because that is poppytosh. XML and SGML specifications are as semantic as you decide to make them. I know people who create perfectly valid XHTML but their pages make no use of headings, lists, blockquotes or the like. Valid but not semantic. -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
Re: [WSG] Is XHTML harmful?
Geoff Deering wrote: I am talking about CSS applied to HTML and the rendering of the CSS as applied to the parsing of the document. But still, strictly speaking, an XML based document is bound to be more semantically correct because it is well formed. This means that the CSS can be applied without fear of the parser misunderstanding where a declaration could have finished. There is no possibility of any guess work in xhtml as it is well formed. You are talking about two distinctly different parsers. XHTML is a XML subset, HTML is an SGML subset. For example: In XHTML: One item Second item Third item This will throw an error because it is bad XML In HTML it will not. With the SGML parser it knows that when it arrives at a new it is the beginning of a new list item. The same would apply, for example, to a paragraph. Surely you don't believe that it would render This paragraph This other paragraph as a paragraph within a paragraph. You need to revise your understandings. HTML is NOT XML. Admittedly, XHTML contains inheritance to certain HTML objects but it is wholly a XML subset. You shouldn't try to argue about parsing when they are parsed by two different types of engines. You're missing the point. Closing tags is being completely accurate with punctuation, where markup is the punctuation. Not closing tags CAN lead to ambiguity. In XHTML there is no syntax ambiguity, in HTML4 there are possibilities. It may not happen when validating against the doctype. Once again you are arguing for ambiguity. It is wrong to assume this. SGML allows for the omission of end tags because it follows a different ruleset -- Paul Connolley SQL/Systems Programmer Egocentric - http://egocentric.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help **
