Re: spurious newlines in lists in tables
On 16 Feb 2009, Keith Hopper wrote: In article 920b6d2e50.roger...@rogerarm.freeuk.com, Roger Darlington roger...@freeuk.com wrote: On 1 Feb 2009, Keith Hopper wrote: In article e45ef42650.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: [snip] Yes, but Netsurf still inserts a space after an end tag - It doesn't if that end tag is /i. So a line like ithis/i with 'this' in italics and a space before the 'with' shows 'thiswith' all next to each other with no space between. How quirky! I must admit to never using the 'i' element as it has been deprecated for some years - but interesting. That so? What single TAG replaces it? But whatever it is, I'm willing to bet Netserf will behave the same way. -- Cheers Roger Vehicles for Roads, Pedestrians for Pavements
Re: Wooo - getting there!
In article 27b3fb2e50.roger...@rogerarm.freeuk.com, Roger Darlington roger...@freeuk.com wrote: What did that removed document say? Good question. I'll have to email him for a copy of it. :-) -- Using, programming and promoting RISC OS - the most productive computer system in the world. Check it out now, and change your view of computers!! To reply/email, visit http://www.riscos.org/contact/ He that is without sin among you, let him first cast a stone.
Re: Graphics refresh problem
In article 88d7ae2e50.roger...@rogerarm.freeuk.com, Roger Darlington roger...@freeuk.com wrote: On 16 Feb 2009, Richard Ashbery wrote: I've looked at it on Firefox on the PC with a 1280 x 1024 monitor and guess what I am unable to see the fourth frame. The problem to which I was replying, Richard, is the second half of Tims response: in that IF you have set Netserf to open a window at less that 1098 pixels, then NONE of the lower frames are displayed until you widen the window yourself. This happens even if you have a 1920 pixel wide monitor. No other browser I have seen (not Firefox nor Safari, nor Explorer, nor Fresco, nor Oregano2) behave this way. Netserf will close all the lower columns again if you make the window narrower than 1098 pixels. I'm a tad surprised the same happens with the latest build. NetSurf r6542 (16 Feb 2009). As a matter of curiosity are there other sites that exhibit this behaviour? Luckily I know Rogers excellent site Many thanks for the compliment Richard. If you have any good flower photographs to contribute, you are welcome to submit them. All contributions acknowledged. Sadly no. Regards Richard
Re: spurious newlines in lists in tables
In article 4cd5fa2e50.roger...@rogerarm.freeuk.com, Roger Darlington roger...@freeuk.com wrote: On 16 Feb 2009, Keith Hopper wrote: In article 920b6d2e50.roger...@rogerarm.freeuk.com, Roger Darlington roger...@freeuk.com wrote: On 1 Feb 2009, Keith Hopper wrote: In article e45ef42650.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: [snip] Yes, but Netsurf still inserts a space after an end tag - It doesn't if that end tag is /i. So a line like ithis/i with 'this' in italics and a space before the 'with' shows 'thiswith' all next to each other with no space between. How quirky! I must admit to never using the 'i' element as it has been deprecated for some years - but interesting. That so? What single TAG replaces it? The element which should be used is the 'em' element and, instead of the 'b' element, use 'strong'. The reason for the others being deprecated is a desire to separate styling from the reason that a content needs a particular style - 'i' and 'b' imply a particular form of styling in visual terms. They are of little use in audio terms, however. I frequently style the 'em' and 'strong' tags in terms of colour rather than font style - sometimes both - such is the flexibility of the cascading style sheet mechanism. Keith -- Inspired!
Re: spurious newlines in lists in tables
On 17 Feb 2009 Keith Hopper wrote: The element which should be used is the 'em' element and, instead of the 'b' element, use 'strong'. The reason for the others being deprecated is a desire to separate styling from the reason that a content needs a particular style - 'i' and 'b' imply a particular form of styling in visual terms. They are of little use in audio terms, however. I frequently style the 'em' and 'strong' tags in terms of colour rather than font style - sometimes both - such is the flexibility of the cascading style sheet mechanism. I'm trying to imagine just how you would intonate 'emphasised' and 'strong' so as to differentiate them. In fact I don't really know what 'strong' means in this context. If I want to emphasise something on the page I would put it into bold text. I use italics to differentiate a particular word or phrase in much the same way as putting quotes round it. If you want full disability access you shouldn't be using colours to convey meaning. Colours are of little use in audio terms. You seem to be saying that we should rigidly stick to particular tags for specific purposes and then in the next breath that you do whatever you want in the stylesheets. This seems not a little inconsistent. -- _ |_|. _ Richard Porter http://www.minijem.plus.com/ |\_||_mailto:r...@minijem.plus.com Disclaimer: Please imagine about 50 lines of pointless clutter.
Content, styling and media [was: spurious newlines
In article ca253e2f50.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: [snip] I'm trying to imagine just how you would intonate 'emphasised' and 'strong' so as to differentiate them. In fact I don't really know what 'strong' means in this context. Neither do I, in general; however, some combination of pauses, rising/falling tones, increased/reduced volume, changing what is known as attack etc are available to the style sheet designer and will be quite as effective as visual forms of styling. The audible effects used, however, are very often also tied to a particular language which in normal use is intoned differently from other languages. If I want to emphasise something on the page I would put it into bold text. I use italics to differentiate a particular word or phrase in much the same way as putting quotes round it. Now when I was under the tutelage of the Leeds University Printer in the early days of computer printing I was told emphasis is always some form of italic or oblique (if no compatible italic face was available) - which does not preclude italic being used for other purposes if needed. Various forms of bold are used for headings and - very very occasionally in combination with italic where emphasised text or italic for some other purposes -does- itself need emphasising. If you want full disability access you shouldn't be using colours to convey meaning. Colours are of little use in audio terms. Indeed - you then use an appropriate @media directive in the style sheet. You seem to be saying that we should rigidly stick to particular tags for specific purposes and then in the next breath that you do whatever you want in the stylesheets. This seems not a little inconsistent. No! If the author wishes to direct that some part of a document should be a heading or a paragraph or emphasised or a list or an aside or image or ... this is the author's prerogative and has nothing at all to do with styling. The person styling the visible or audible result will then be free to decide which 'effects' to make use of in concretion of the author's wishes. This is entirely proper - a bit like the way a publisher takes an author's 'manuscript' and in consultation with a master printer and a type designer decides on the style which will be used for various features of the text. Where a browser user has particular needs or restrictions then he/she is able to define their own style rules - if needs be labelling them !important to over-ride what the original stylist specified as and if necessary. It is a bit difficult doing that for a print medium in the publishing business - so - one up to style sheets and browsers. A little longer than I originally intended, but I hope I have adequately explained the content, styling and media differences. Keith -- Inspired!
Deprecated elements [was Re: spurious newlines
In article 502f456d69...@timil.com, Tim Hill t...@timil.com wrote: In article ca253e2f50.r...@user.minijem.plus.com, Richard Porter r...@minijem.plus.com wrote: On 17 Feb 2009 Keith Hopper wrote: The element which should be used is the 'em' element and, instead of the 'b' element, use 'strong'. The reason for the others being deprecated they're not May I refer you to http://webdesign.about.com/od/htmltags/a/bltags_deprctag.htm Keith -- Inspired!